The adaptive HTTP streaming techniques rely on the client selecting media quality. The server or content provider describes all available quality representations and the way of fetching them in a so called manifest file, for example the representations of the media content may differ regarding the different media bitrates and the way to access the representations from the server. The manifest file is fetched at least once at the beginning of a streaming session and may be updated during the session. DASH Dynamic adaptive streaming over HTTP is an adaptive streaming technique, which adjusts the media stream to the currently available link bitrates as disclosed in “Dynamic adaptive streaming over HTTP (DASH)—Part 1: Media presentation description and segment formats”, ISO/IEC 23009-1:2012(E), Version 2.1c2.
DASH is designed as a client controlled adaptive HTTP streaming protocol. That means, that the server describes a set of available media qualities for example in a manifest file and the client selects depending on the link bitrate the media representation (i.e. media bitrate) matching the link bitrate. In general the DASH solution comprises a DASH server being adapted to provide content with different media qualities, so called representations and on the client side a DASH client is adapted to request the media content with different qualities.
Most of the adaptive HTTP Streaming techniques require a client to continuously fetch media segments from a server. A certain amount of media time (e.g. 10 sec of media data) is contained in the media segment. Each segment of a particular media representation is made available at the server at a particular time indicated in the manifest. The way of creation of the URLs on the client side for downloading the segments of the different quality representation is described also in the manifest.
FIG. 1 depicts the principle of segments fetching in a DASH environment. The client, a DASH client communicates with a server, a DASH server.
The manifest file is received as an answer of the HTTP GET manifest file message, 10, and processed to determine the possible qualities, 11. In the next step, 12, the client requests data at lowest quality, HTTP GET Segment#1 from Lowest Quality and a measurement of the downloading rate is performed, 13. The client continuously measures the link bitrate while receiving the media segments, 14, to determine the appropriate quality for the reception of the content data. The client may change to another quality representation at any time, if a decision is taken to change the representation, 15. In the embodiment according to FIG. 1, it is decided to request media data with a medium quality, HTTP GET Segment#2 from Medium Quality, 16, and to continue the measurement of the download rate, 17.
The manifest file needs to be available in order to process the media content being divided into media segments. The manifest file may be distributed separately, optionally in-band with the stream or via a separate service announcement method. In case of Apple's HLS, the manifest is formatted as a Playlist file in m3u8 format. In case of 3GPP/MPEG DASH, the manifest is an XML structure called MPD Media Presentation Description file. The MPD comprises lists or means to generate the lists of the URLs of all media segments, which belong to the media session and which are used to fetch the next media segment.
There is also the possibility to deliver DASH media segments over broadcast systems such as eMBMS (LTE Multimedia Broadcast Multicast Service). Broadcast is efficient, when many users in a cell or any broadcast area use the same bitstream quality. Thus, it is possible that the same service is broadcasted for example in urban areas at a higher bitrate and with a lower bitrate in sub-urban areas simultaneously to a number of users.
Thus, the DASH player may receive content via broadcast or unicast. However a DASH Player has no information, whether the phone is within broadcast and/or unicast coverage. A Live Encoder LE at the server side generates a MPD and is also not aware of whether this file is to be used by unicast or broadcast and in many cases the same content will be distributed both on unicast and broadcast.
Furthermore, the DASH operates by segmenting the continuous media content stream into a sequence of media segments. A DASH segment is typically subdivided by the Live Encoder LE or Segmenter into multiple transport protocol segments, like a TCP or UDP segments, wherein the segments have a roughly constant duration of time, the so called segment duration.
A new MPD is fetched from the server when the current playback time gets close to the end of the media described in the MPD, or reaches a time since last check that is longer than the minimal update time signalled in the MPD.
The media segments are on average 100 kByte size, however some may be larger, e.g. up to 130 kByte and some smaller, e.g. up to 70 kByte, then when generating the media segments, each segment having a segment duration might have a different number of TCP or respectively of UDP segments. The segment size depends also on the chosen representation. The client can choose to switch among representations to adapt the bitrate. Finally the client fetches the sorted sequence of files and concatenates back the files into a continuous media stream and the content is played out and segments are continuously requested.
When running DASH over LTE Broadcast (eMBMS), the Live Encoder uploads the media segments into a Broadcast Multicast Service Center (BM-SC). FLUTE protocol in the BM-SC cares about partitioning the media file into a sequence of media segments, here of UDP packets or segments. Each UDP packet is uniquely marked with a sequence number, so that the client can re-assemble the file.
The IETF FLUTE protocol (RFC 3926) is used for file delivery over a broadcast transmission. The FLUTE delivery session is defined by an SDP (Session Description Protocol) file, which contains all parameters such as IP Multicast address, UDP port and but also a TMGI (Temporary Mobile Group Identity) for MBMS to allow a client to receive a mobile file broadcast delivery. Thus, FLUTE is a protocol, which allows delivery of files over broadcast links using UDP as a transport protocol.
The DASH Player fetches a sequence of media segments as independent files using the URL as provided in the manifest (called MPD in case of DASH). When sending DASH over MBMS, the segments are not fetched by the client from the remote server. Instead, the segments are pushed using FLUTE over broadcast.
In the broadcast scenario, a media segment must be first received by the eMBMS client, before it can be made available to the DASH player. This is a penalty for broadcasted representations over unicast representations. The DASH player does not know, whether or not the UE (User Equipment) is within broadcast coverage. The DASH player orders the subsequent data segments at the time as stated in the MPD file. However in case of broadcast at the requested time the media segment may not be available at the server, and not in the local cache at UE. Thus, the DASH player asks for a segment which is not received yet.
Also in case of broadcast the segments are on average 100 kByte size, some are larger, e.g. up to 130 kByte and some are smaller, e.g. up to 70 kByte, then when generating the segments, each segment might have a different number of UDP segments. In case of broadcast there is a constant bitrate bearer allocated for broadcast transmission. For example the allocated bitrate might be 1 Mbps that means that it takes 0.5 sec for a segment of size 500 kb to be transmitted and a segment of size 1500 kb needs 1.5 sec. The different size of the media segments leads to varying segment duration during the transmission of the segment and consequently the reception time interval for a complete reception of a media segment varies. However, the DASH Player assumes that media segments are made available with a fixed interval, namely segment duration.
Furthermore, the end to end delay between the BM-SC down to the UE differs from a system to another. It depends on how certain parameters have been configured on the eNodeB, but also on the network deployment. The speed of the BM-SC hardware has also an impact on the end-to-end system. For this reason the end-to-end delay can largely differ between different vendors and even between two systems served by different BM-SC when providing media segments.
However, these different systems are served by one live encoder for which the system deployments are completely transparent. Therefore the LE generates on one side different segment sizes, which take respectively different time duration for the transmission via a network and on the other side due to the varying end-to-end delay in the network, the variation in the time transmission of a media segment is intensified.
Furthermore, UEs are not always time synchronized with the system. Some form of mobile device clock time synchronization is necessary because hardware clocks drift from each other over time, with different clocks from different platforms having different drift rates depending on device characteristics and external effects of variations in temperature, vibration, and humidity. There is a well-known issue that various devices from different operators have time accuracy issues. Some only a few seconds, some a few minutes or more. Consequently, the drift rates of the clocks influence further the different segment reception time of the media segments.
Further, MPEG DASH uses the wallclock time to calculate the segment availability on the server. That requires that UEs are properly time-synchronized with the system, so that the UE can precisely calculate the reception of the most recent media Thus, all the mentioned aspects leads to increasing of the varying transmission duration of media segments over the constant bitrate bearer and consequently in varying of time intervals in reception of media segments leading to situation that the DASH player when ordering the subsequent segment may get regularly an error message, if the media segment is not available by the requested time.